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ABSTRACT 

XMM, ESA's X-Ray Multi-Mirror 
satellite, due for launch at the end of 
1999 will be the first ESA scientific 
spacecraft to implement the ESA 
packet telecommand and telemetry 
standards and will be the first ESOC- 
controlled science mission to take 
advantage of the new flight control 
system infrastructure development 
(based on object-oriented design and 
distributed-system architecture) due 
for deployment in 1995. 

The implementation of the packet 
standards is well defined at packet 
transport level. However, the standard 
relevant to the application level (the 
ESA Packet Utilisation Standard) 
covers a wide range of on-board 
services" applicable in varying 
degrees to the needs of XMM. In 
defining which parts of the ESA PUS 
to implement, the XMM project first 
considered the mission objectives and 
the derived operations concept and 
went on to identify a minimum set of 
packet definitions compatible with 
these aspects. 

This paper sets the scene as above 
and then describes the services 
needed for XMM and the 
telecommand and telemetry packet 
types necessary to support each 
service. 


INTRODUCTION 

The introduction of packet TM and TC 
standards (Refs 1 and 2) has lead to a 
high degree of transparency in the 
operational interfaces between 
satellite on-board systems and the 
related ground systems, offering 
designers the potential for liberal 
definition of the data to be 
transported within TM and TC 
packets. The complexity of the 
on-board and ground systems can be 
greatly influenced by the 

o the type of interaction (or 
service) and 

o the structure and content of 
the packets used in this 
interaction 

Only by careful definition of the 
packet structures and content can it 
be ensured that the satellite is 
provided with the information it needs 
(within command packets) for its 
operations functions and that the 
ground is provided with the 
information it needs (within telemetry 
packets) for execution of its 
operational tasks. This becomes even 
more significant now that satellite 
systems are increasingly implemented 
using on-board software. 

In preparing for the XMM satellite 
development programme, it was 
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necessary to define the on-board 
services that will be needed to allow 
the XMM Flight Control System to 
undertake all mission operations. The 
services needed are driven by the 
mission objectives and the associated 
concept for conduct of the operations 
needed to satisfy these objectives. 

The ESA Packet Utilisation Standard 
(ESA PUS) (Ref 3) was the reference 
standard for this the application-level 
interface and defines a wide range of 
services considered necessary for all 
future (unmanned) missions. The 
process of selecting services from the 
PUS and tailoring the packet related 
packet structures to suit the particular 
needs of any particular mission is 
referred to as "missionisation". 


XMM OPERATIONS CONCEPT 

The X-ray Multi-Mirror satellite (XMM) 
is an observatory in the soft X-ray 
region of the electromagnetic 
spectrum and is due for launch on 
Ariane 5 late in 1 999. By virtue of the 
large collecting area of its telescope 
and the highly eccentric orbit, XMM 
will be able to perform long 
observations (upto 16 hours above 
40,000 Km) of X-ray sources with an 
unprecedented sensitivity. 

The satellite and its X-ray instruments 
will be controlled in real time from the 
European Space Operations Centre in 
Darmstadt, Germany, and employing 
a single ground station, will benefit 
from upto 22 hours of telemetry and 
telecommand contact every day. All 
science and housekeeping data will be 


transmitted in real time to the control 
centre for immediate processing (no 
bulk storage on board). In view of the 
on-line nature of satellite operations 
and the nearly continuous visibility 
from the ground and the desire to 
minimise on-board complexity, it was 
appropriate to identify straightforward 
almost "classical" ways for ground 
on-line control of the satellite while 
making use of the advantages offered 
by packets. The concept for safety 
management during planned (and 
unplanned) non-contact periods was 
defined to involve the use of delayed 
execution (time tagged) commands, a 
low degree of on-board monitoring 
and provision of a history of on-board 
events. Further, it was necessary to 
provide for operations maintenance in 
the form of telemetry management 
and definition and interaction with on 
board software. 


XMM FLIGHT CONTROL SYSTEMS 

A further constraint on definition of 
the ground/satellite interactions and 
hence the TM/TC services needed, 
relates to the Flight Control Systems 
infrastructure foreseen for XMM. 
Flight Control Systems for past 
missions (not utilising packets) 
involved handling of the individual 
characteristics of the TM/TC schemes 
by mission-specific software modules 
interacting with kernel systems 
offering basic functions only. These 
additional modules were needed to 
convert the peculiarities of the 
satellite data structures into a form 
processable within the kernel systems 
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and understandable to the Flight 
Operations Teams. 

Recent advances in ground system 
technology (for example in the use of 
distributed workstation-based control 
systems and object-oriented 
techniques) now allow the 
development of multi-mission control 
systems offering a palette of services 
to potential users (missions). By 
defining data structure standards 
across the board, commonality 
between missions can be increased 
leading to a corresponding reduction 
in the need for mission-specific 
elements. This is the ultimate goal of 
the ESA PUS, a document now 
entering the approval stage. 

The PUS defines the various 
operational requirements for on board 
functions and services and goes on to 
describe the TM/TC packet types and 
structures needed to support these 
services. The PUS then defines the 
format and content of the (variable) 
"Packet Data Field" being the user- 
defined part of the packet and 
including the "Source Data" for 
telemetry (Figure 1) and the 
"Application Data" for commands 
(Figure 3), The PUS further prescribes 
how the "Data Field Header", within 
the Packet Data Field is to be used 
(Figures 2 and 4) : two fixed fields in 
this header are reserved for 
identification of the Packet Type and 
Packet Subtype . In this way, every 
packet in the ground or on-board 
systems is clearly identifiable in terms 
of its function and the processing 
needed. 


XMM however, with its classical 
operations concept did not need to 
take advantage of the wide range of 
services available within the PUS : 
using the PUS as a starting point, the 
XMM project selected those services 
and related data structures of use in 
supporting the operational 
requirements (as documented in Ref 
4) for all foreseen XMM mission 
scenarios . 


XMM SERVICES 

The services defined for XMM mission 
operations can be considered to fall 
into three major categories as follows 
(as documented in Ref 5): 

1) ON-LINE CONTROL 

Periodic Housekeeping Telemetry (TM 
Type — 11 is required to permit the 
ground to derive and monitor the 
status, health and performance of the 
satellite systems and instruments. 

Device Commands (TC Tvoe 2) are 
required to configure the on board 
hardware using two subtypes : 

Pulse commands (Subtype 1 ) 
Register load commands 
(Subtype 2). 

Tele command Verification Serving 
(TM Type 3) is required to allow the 
ground to positively verify all uplinked 
commands. Dedicated packets are 
required for each uplinked command 
indicating 

Successful Acceptance 
(Subtype 1) 
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Unsuccessful Acceptance 
(Subtype 2) 

Successful Execution (Subtype 
3) 

Unsuccessful Execution 
(Subtype 4) 

Non-Periodic Telemetry (TM Type 4) 
is required to convey information 
related to non-periodic events (not 
contained in the periodic telemetry) to 
the ground. The service must provide 
for 

Event Reports (Subtype 1) for 
events of operational 
significance 

Exception Reports (Subtype 2) 
for notification of non-fatal 
errors 

Major Anomaly Reports 
(Subtype 3) for notification of 
major on-board anomalies 

Task Management Service (TC Type 
51 is required to control and interact 
with on-board software tasks. The 
service must provide for 

Start task (Subtype 1 ) 

Stop task (Subtype 2) 

Load task functional 
parameters (Subtype 3) 

Mode Transition (Subtype 4) 

Science Telemetry (TM Type 15) is 
required to transport data from the 
XMM science instruments to the 
ground. 

2) SAFETY MANAGEMENT 

Time Tag Commands (TC and TM 
Type 7) are required to effect 
operations requiring well-defined 
execution times or which need to be 


executed in periods of non coverage 
or to ensure that the satellite is 
returned to its nominal state after any 
critical operation. The service must 
provide for 

Load a command into the 
time-tag buffer (Subtype 1) 
Report a summary of the 
contents of the time-tag buffer 
(Subtype 2) 

Report all commands in the 
time-tag buffer in detail 
(Subtype 3) 

Report a selected command in 
the time-tag buffer in detail 
(Subtype 4) 

Delete a selected command 
from the buffer (Subtype 5) 
Delete all commands in the 
time-tag buffer (Subtype 6) 

On-Board Monitoring Service (TC and 
IM Type 8) is required to monitor a 
maximum of 30 parameters during 
periods when the ground does not 
have visibility of the spacecraft and to 
retain the results. The service must 
provide for 

Enable and refresh monitoring 
(Subtype 1) 

Disable monitoring (Subtype 2) 
Add to monitoring list (Subtype 

3) 

Delete monitoring list (Subtype 

4) 

Report the monitoring list 
contents (Subtype 5) 

Report the results of 
limit/status checks (Subtype 6) 
Report the minimum and 
maximum values over the 
period enabled (Subtype 7) 
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Non-Periodic Packet Storage Serving 
(TC Type 1 1) is required to store all 
non-periodic packets (TC verifications 
reports, event reports, exception 
reports and major anomaly reports) in 
a cyclic buffer to permit the ground 
access to non-periodic packets 
generated at times when the ground 
has no contact with the satellite 
(planned and unplanned). The service 
must provide for 

Report stored packets (Subtype 
1 ) 

Enable and refresh packet 
storage (Subtype 2) 

Disable packet storage 
(Subtype 3) 

3) OPERATIONS MAINTENANCE 

Memory Maintenance Service (TC anH 
IM Type 6). is required to allow the 
ground to maintain the on-board 
software as needed to compensate 
for hardware failures, to resolve 
software non-compliance with design 
requirements, to account for new 
requirements or to enhance system 
performance. The service must 
provide for 

Load memory (Subtype 1) 

Dump memory (Subtype 2) 
Calculate Memory Checksum 
(Subtype 3) 

Telemetry Management Service (Tr 
and TM Type 9) is required to manage 
generation of telemetry packets by 
any particular application (on board 
subsystem or instrument). The service 
must provide for 

Report packet generation status 
(Subtype 1) 


Enable generation of all TM 
packets (Subtype 2) 

Disable generation of all TM 
packets (Subtype 3) 

Enable generation of specific 
TM packets (Subtype 4) 
Disable generation of specific 
TM packets (Subtype 5) 

Telemetry Definition Service (TC and 
TM Type 10) is required to allow the 
ground to define new housekeeping 
packets (for the satellite systems 
only) if necessary for troubleshooting 
or anomaly rectification. The service 
must provide for 

Report new housekeeping 
packet definitions (Subtype 1 ) 
Define new housekeeping 
packet (Subtype 2) 

Delete new housekeeping 
packet definition (Subtype 3) 

Test Commands (TC Type 13) are 
required to confirm that the on-board 
link to any application is alive. 


DATA STRUCTURES 

The definition of packet types is only 
completed when the data structures 
needed for each of the identified 
packets types and subtypes are 
expanded down to field level as is 
foreseen in the PUS. The purpose of 
each field, its length and its format 
must finally be agreed between 
satellite system and ground system 
developers. This final stage in the 
missionisation process for XMM has 
been initiated and is also documented 
in Ref 5. 
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CONCLUSION 
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Figure 1. Telemetry Source Packet Fields (from Ref 1) 
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Figure 2. Telemetry Packet : Data Field Header (from Ref 5) 
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Figure 3. Telecommand Packet Fields (From Ref 2) 
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Figure 4. Telecommand Packet : Data Field Header (from Ref 5) 
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